docs: mark cross-host presence experimental - #107

Why

Cross-host presence is not reliable enough to serve as health or lifecycle authority. Under ordinary content replication, a same-value status refresh may update host-local freshness metadata without changing file bytes; a remote observer can then age the unchanged value to unknown. The current replication mechanism gap is tracked in compoundingtech/fabric#27.

What

• mark cross-host presence as EXPERIMENTAL and best-effort in st2 agents --help
• state that ordinary replication may be delayed, stale, or asymmetric
• define a remote unknown as no fresh observation, not proof that an agent or host is unhealthy
• state that cross-host presence never gates local work or triggers restart, teardown, reconciliation, or a global-fleet health conclusion
• keep host-local runtime and service evidence authoritative for lifecycle decisions
• add a focused CLI-help regression test covering every boundary above

Impact

This changes help text only. It does not change presence calculation, status refresh, doctor behavior, reconciliation, restart, teardown, service behavior, catalog data, or runtime state. It introduces no peer type or health classification.

Checks

• cargo run --quiet -- agents --help — rendered wording inspected
• cargo test --test status_agents -- --nocapture — 4 passed
• cargo test --lib status::tests -- --nocapture — 9 passed
• cargo clippy --test status_agents -- -D warnings -A clippy::too_many_arguments — passed; the allowance is for an unrelated current-main lint in eval_run::wait_done
• git diff --check — passed
• cargo fmt --check — current-main baseline remains broadly red across unrelated files; this patch does not reformat them

Base: c6846f6239329f0803142afc06c15a07b93937c1.